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Abstract 


The cryptographic algorithm and key size requirements included when 
DomainkKeys Identified Mail (DKIM) was designed a decade ago are 
functionally obsolete and in need of immediate revision. This 
document updates DKIM requirements to those minimally suitable for 
operation with currently specified algorithms. 


Status of This Memo 
This is an Internet Standards Track document. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Further information on 


Internet Standards is available in Section 2 of RFC 7841. 


Information about the current status of this document, any errata, 
and how to provide feedback on it may be obtained at 
https://www.rfc-editor.org/info/rfc8301. 
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1. Introduction 


DKIM [RFC6376] signs email messages by creating hashes of the message 
headers and content and signing the header hash with a digital 
signature. Message recipients fetch the signature verification key 
from the DNS where it is stored in a TXT record. 


The defining documents, RFC 6376 [RFC6376] and its predecessors, 
specify a single signing algorithm, RSA [RFC8017], and recommend key 
sizes of 1024 to 2048 bits (but require verification of 512-bit 
keys). As discussed in US-CERT Vulnerability Note VU#268267 
[VULNOTE], the operational community has recognized that shorter keys 
compromise the effectiveness of DKIM. While 1024-bit signatures are 
common, stronger signatures are not. Widely used DNS configuration 
software places a practical limit on key sizes, because the software 
only handles a single 256-octet string in a TXT record, and RSA keys 
significantly longer than 1024 bits don’t fit in 256 octets. 


Due to the recognized weakness of the SHA-1 hash algorithm (see 
[RFC6194]) and the wide availability of the SHA-256 hash algorithm 
(it has been a required part of DKIM [RFC6376] since it was 
originally standardized in 2007), the SHA-1 hash algorithm MUST NOT 
be used. This is being done now to allow the operational community 
time to fully shift to SHA-256 in advance of any SHA-1-related 
crisis. 


2. Conventions Used in This Document 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", “SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 
"OPTIONAL" in this document are to be interpreted as described in 
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 
capitals, as shown here. 
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3. Updates to DKIM Signing and Verification Requirements 
This document updates [RFC6376] as follows: 
o Section 3.1 of this document updates Section 3.3 of [RFC6376]. 
o Section 3.2 of this document updates Section 3.3.3 of [RFC6376]. 


o The algorithm described in Section 3.3.1 of [RFC6376] is now 
historic and no longer used by DKIM. 


Sections 3.3.2 and 3.3.4 of [RFC6376] are not affected. 
3.1. Signing and Verification Algorithms 


DKIM supports multiple digital signature algorithms. Two algorithms 
are defined by this specification at this time: rsa-shal and 
rsa-sha256. Signers MUST sign using rsa-sha256. Verifiers MUST be 
able to verify using rsa-sha256. rsa-shal MUST NOT be used for 
signing or verifying. 


DKIM signatures identified as having been signed with historic 
algorithms (currently, rsa-shal) have permanently failed evaluation 
as discussed in Section 3.9 of [RFC6376]. 


3.2. Key Sizes 


Selecting appropriate key sizes is a trade-off between cost, 
performance, and risk. Since short RSA keys more easily succumb to 
off-line attacks, Signers MUST use RSA keys of at least 1024 bits for 
all keys. Signers SHOULD use RSA keys of at least 2048 bits. 
Verifiers MUST be able to validate signatures with keys ranging from 
1024 bits to 4096 bits, and they MAY be able to validate signatures 
with larger keys. Verifier policies can use the length of the 
signing key as one metric for determining whether a signature is 
acceptable. Verifiers MUST NOT consider signatures using RSA keys of 
less than 1024 bits as valid signatures. 


DKIM signatures with insufficient key sizes (currently, rsa-sha256 
with less than 1024 bits) have permanently failed evaluation as 
discussed in Section 3.9 of [RFC6376]. 


4. Security Considerations 
This document does not change the Security Considerations of 
[RFC6376]. It reduces the risk of signature compromise due to weak 


cryptography. The SHA-1 risks discussed in Section 3 of [RFC6194] 
are resolved due to rsa-shal no longer being used by DKIM. 
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derations 


dated the Reference and Status fields of the "shal" 


registration in the "DKIM Hash Algorithms" registry. The 
registration now appears as follows: 
+------ 4+—--------------------- +---------- + 
| Type | Reference | Status | 
+------ 4+—--------------------- +---------- + 
| shal | [RFC6376] [RFC8301] | historic | 
+------ 4+—--------------------- +---------- + 
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